1. Field of the Invention
The present invention is related to the field of network provisioning servers.
2. Background Art
Existing provisioning servers for Internet Protocol (IP) address based networks commonly offer minimal functionality needed by Multiple Subscriber Organization (MSO) service providers geared for enterprise networking. MSO operators desire enhanced functionality in several areas to allow them to deliver advanced services and increased operational efficiencies. The enhanced functionality sought includes the areas of IP address allocation, network lease customization, modular server configurations with some standard database interfaces, support for client roaming across multiple networks, and network renumbering.
As the number of clients grows, the MSO service provider is faced with the challenges of expanding the services to meet the increased demand, and customizing the services to meet the widening variety of needs presented by the individual customers. Some Dynamic Host Configuration Protocol (DHCP) and dynamic Bootstrap Protocol (BOOTP) provisioning servers allow for low level assignment of network leases at the individual client level, however, they are usually limited either by functionality or scalability. A common approach is to create a customized bootfile for each client or client type. This approach required large memory allocations to store many bootfiles, which in turn makes maintenance, redundancy and growth difficult. Each new client or client type means another bootfile, most of which is a duplication of other client or client type bootfiles. The storage requirements are compounded when redundant provisioning servers are in use and each server has an independent copy of each bootfile. Making a fundamental change to the thousands of bootfiles, say to add new options to an existing service, becomes a problem due to the sheer number of files that must be edited and verified. Some attempts have been made to bound these problems by storing all of the client information outside the provisioning servers on a common database. These attempts have met with limited success due to the lack of a standard interface between the databases and the provisioning servers designed by different vendors.
Another challenge faced by the MSO service providers is a limited block of IP addresses they are allowed to lease to their clients who want Internet access. To help conserve IP addresses, non-routable network addresses are frequently used for point-to-point links, nonessential equipment, and cable modems. To be effective, the provisioning servers must be able to distinguish when to provide non-routable addresses and when to provide routable IP addresses. Static assignments and subnet-less specific assignments are two commonly used methods for distinguishing the IP address types. Static assignments permanently link a particular client to a specific IP address or reserve a specific IP address for another purpose, such as a router interface. Static assignments are maintenance intensive as the provisioning server must be informed of each static IP address assignment before the client can access the network. Static assignments are also inefficient with IP address usage because the assignments remain in place even after the client no longer needs the IP address.
Subnet-less specific assignments are used by most of the DHCP servers set up to handle multiple networks. In a subnet-less specific model, a relay agent (e.g., routers) provides a logical link that defines the IP address range from which the DHCP server should dispense IP addresses. This logical link is configured in the DHCP server such that the relay agent's primary IP address identifies the network address range the server should use to satisfy valid requests from clients for IP addresses. In some situations, valid requests may be only those that come from clients registered with the MSO service provider. Requests from unregistered clients may be ignored. In other situations, requests from registered and unregistered clients are treated alike. However, this model is limited when non-routable secondary address ranges are assigned to specific devices because the subnet-less assignment model will treat all related address blocks as one continuous block. Multiple DHCP servers must be installed in order to have multiple IP address blocks. This solution is costly as hardware must be added for each additional service variation. More intelligence is also required to register the clients to the proper DHCP server associated with the service class for which the client is paying.
Where the MSO operator provides network services over a wide area, it is very likely that some clients will “roam” from one network to another network within the area. The proliferation of laptop computers, telecommuting and the like allows clients to connect their hardware into the MSO's networks from multiple locations all within the same day. For example, the client may start the morning downloading e-mail at their home, connect their laptop to the network at their office later in the day, and then plug their computer into a public network port at a library in the evening. Network roaming is currently supported on DHCP servers by an auto-release function. Auto-release allows a client who has moved from a previous network to a new network to receive a new lease on the new network while releasing the previous lease on the previous network. When the client returns to the previous network, they receive their previous lease.
Auto-release creates problems for system troubleshooting because it allows one client to have several leases simultaneously. When a client holding multiple leases experiences network problems, the MSO personnel are faced with a difficult task of sorting through the multiple leases to find the current lease. To maintain a one lease per client model, variations of the auto-release function have been used that result in the permanent removal of the previous lease. A drawback of this variation is that when the client returns to the previous network, the client is unlikely to receive the same previous lease. This may cause problems for the client when, for example, the client's login to a protected system is keyed to the client's IP address.
The one lease per client model is also a consideration when a network is renumbered and all of the clients on that network must obtain new IP address leases. Network renumbering is usually caused by an expanding client base exceeding the IP address availability. The renumbering process moves the clients from their existing block of IP addresses to a larger block that can accommodate the needs. The clients undergo a process whereby their existing gateway is changed to a newly introduced network. In this new network, the client leases become invalid and they must invoke some surrender (e.g., DHCP release) and acquisition (e.g., DHCP discover) process to obtain a working lease from the provisioning server for the new network. Inefficiency in the renumbering process often causes clients more than a momentary loss of network services. The worst case outage for a client during the renumbering process is due to the period between the renewal time and the rebind time. Once the renewal time is reached, the clients will attempt to send a uni-cast message to the provisioning server to renew the lease. However, once the gateway address has been changed to the new network, uni-cast renewal messages through the old gateway address will not reach the provisioning server. The clients will not talk to the provisioning server again until they reach their rebind time and broadcast their rebind messages independent of the new gateway address. This delay in client reconfiguration can be significantly reduced if the client leases were aligned with the change of the gateway address to the new network.